Bac NSI 2025 Nouvelle-Calédonie jour 2

m2 = code(m1, cle)

On applique une seconde fois la transformation avec la même clé. La propriété donnée garantit alors m2 == m0. Mais Eve a reçu à la fois m1 et cle : elle peut effectuer exactement la même opération. Le problème vient donc de la transmission de la clé sur le canal observé, pas d’une erreur dans cette instruction.

m2 = code(m1, cle2_b)

La transformation inverse emploie l’autre clé de la paire de Bob. Il faut choisir la clé du destinataire Bob, et non une clé d’Alice. Comme m1 a été créé avec cle1_b, l’application de cle2_b retrouve m0.

Eve connaît le chiffré m1 et la clé publique cle1_b. Pour inverser ce chiffrement, elle aurait besoin de cle2_b, que Bob n’a pas publiée. Le sujet suppose qu’il est impossible de la déduire de cle1_b et de déchiffrer sans elle.

Cette conclusion utilise bien les hypothèses du modèle : notamment, la clé publique reçue doit être celle de Bob. Empêcher Mallory de substituer une autre clé demanderait d’authentifier cette clé, par exemple au moyen d’un certificat dans un protocole réel.

Pour Bob : cle1_b est publique et cle2_b est privée. De même, Alice publie cle1_a et conserve cle2_a. Le statut public ou privé vient de la règle de diffusion, pas d’un rôle immuable « chiffrement » ou « déchiffrement » dans le modèle abstrait.

# Chez Bob
reponse = 'Bien reçu. Rendez-vous à 16h donc.'
reponse_chiffree = code(reponse, cle1_a)
# Bob transmet reponse_chiffree à Alice.

# Chez Alice
reponse_lue = code(reponse_chiffree, cle2_a)

Le destinataire a changé : on utilise donc la paire d’Alice. Bob peut accéder à sa clé publique pour préparer l’envoi, tandis qu’Alice possède seule la clé privée inverse. Chiffrer avec la clé privée de Bob ne cacherait pas ce message : tout le monde dispose de sa clé publique pour inverser l’opération selon le modèle.

Alice doit disposer d’une information lui permettant de préparer un message que seul Bob pourra ouvrir. La clé publique remplit le premier rôle sans révéler l’information secrète nécessaire au second. Avec une unique clé symétrique, Alice devrait connaître le même secret que Bob et il faudrait le partager par un canal sûr avant leur premier échange.

Deux clés permettent ainsi de séparer « autoriser tout le monde à m’envoyer un secret » de « m’autoriser seul à lire ce secret ». Il ne s’agit pas de doubler arbitrairement une clé : les deux clés ont des rôles complémentaires.

authentique = (code(m0_s, cle1_a) == m0)

Bob transforme la signature avec la clé publique authentique d’Alice et compare le résultat au message reçu. La signature a été produite avec cle2_a : selon les hypothèses du sujet, seul son détenteur pouvait fabriquer cette signature du message.

Si Mallory remplace seulement m0 par m3, le résultat obtenu à partir de la signature reste m0 et ne correspond plus au texte reçu. Fabriquer la bonne signature de m3 nécessiterait la clé privée d’Alice. Une simple mention « Signé : Alice » dans le texte ne fournit, elle, aucune preuve.

Le contenu reste public dans cette partie : la signature apporte une vérification de l’origine et de l’intégrité dans ce modèle, pas la confidentialité.

5.

Pour comprendre le calcul après avoir répondu : 1 × |97 - 98| + 2 × |99 - 97| = 1 + 4 = 5. Le premier caractère sert au premier écart ; il n’ajoute pas un terme d’indice zéro.

def reduction(s):
    total = 0
    for i in range(1, len(s)):
        total += i * abs(ord(s[i]) - ord(s[i - 1]))
    return total

Le parcours commence à 1 pour que s[i - 1] désigne toujours le caractère précédent, et s’arrête au dernier caractère. À chaque tour, on calcule la différence des codes, on prend sa valeur absolue, puis on multiplie par l’indice courant.

L’ordre des opérations compte : appliquer abs à la somme finale ne reproduirait pas la somme des valeurs absolues demandée. Pour une chaîne vide ou de longueur 1, il n’existe aucune paire consécutive ; la boucle est vide et le résultat vaut 0.

assert reduction('abca') == 9
assert reduction('bac') == 5
assert reduction('') == 0
assert reduction('a') == 0
assert reduction(m0) == 62073
assert reduction(m3) == 53681

empreinte_recue = code(m0_s, cle1_a)
empreinte_calculee = str(reduction(message_recu))
coherent = (empreinte_recue == empreinte_calculee)

Bob vérifie la signature avec la clé publique d’Alice et recalcule lui-même l’empreinte du texte reçu. La conversion str est nécessaire : la fonction code manipule des chaînes, alors que reduction renvoie un entier. Dans l’exemple, substituer m3 donne "53681" au lieu de "62073" et la comparaison échoue.

Limite de cette réduction : deux messages distincts peuvent avoir la même valeur. Par exemple reduction('abc') == reduction('cba') == 3. La comparaison décrit bien le mécanisme demandé, mais cette réduction pédagogique ne permet pas de garantir l’authenticité de n’importe quel texte : une véritable signature compacte utilise une fonction de hachage cryptographique adaptée.

Elle laisse toute la fin du message hors du contrôle. Mallory peut modifier le rendez-vous, l’adresse ou un autre passage situé après le préfixe signé sans changer la réduction. Dans cet exercice, les deux messages commencent par le même préfixe Rendez-vous : une réduction limitée au début ne distinguerait même plus le faux rendez-vous donné.

Réduire le travail de calcul en ignorant une partie du message ne résout donc pas le problème de sécurité. Pour une empreinte utile, chaque partie du texte doit influencer le résultat ; cela reste une condition nécessaire, mais pas suffisante, puisqu’il faut aussi rendre la recherche de collisions difficile.

Il faut combiner deux paires et deux objectifs : la clé publique de Bob pour la confidentialité vers Bob, et la clé privée d’Alice pour une signature d’Alice. Dans le modèle de la partie C, on peut signer le message complet pour éviter la faiblesse de la réduction étudiée :

# Chez Alice
signature = code(m0, cle2_a)
message_chiffre = code(m0, cle1_b)
signature_chiffree = code(signature, cle1_b)
# Envoyer message_chiffre et signature_chiffree.

# Chez Bob
message_lu = code(message_chiffre, cle2_b)
signature_lue = code(signature_chiffree, cle2_b)
authentique = (code(signature_lue, cle1_a) == message_lu)

Bob doit posséder sa clé privée pour ouvrir les deux éléments transmis. Il vérifie ensuite que la signature d’Alice correspond exactement au contenu déchiffré. Chiffrer également la signature complète empêche Eve de retrouver le message en lui appliquant la clé publique d’Alice.

On peut garder une signature plus courte en signant l’empreinte comme dans la partie D, puis en chiffrant message et signature pour Bob ; la vérification compare alors les empreintes. Mais avec la réduction simplifiée de cet exercice, cela conserve le risque de collision expliqué à la question 10. Pour une garantie réelle, il faut une fonction de hachage et un schéma de signature cryptographiques adaptés, ainsi que des clés publiques authentifiées.

Une clé primaire identifie sans ambiguïté chaque ligne d’une relation. Ses valeurs doivent être uniques et non nulles. Deux clients ne peuvent donc pas partager une même valeur de ref_client.

Une clé peut être composée de plusieurs attributs ; l’unicité porte alors sur leur combinaison. Le nom d’un client ne convient pas à lui seul si des homonymes sont possibles, même si les quelques lignes de l’extrait ont des noms différents.

Emile Pasteur possède la référence client 25145. La vente 25634 indique un achat le 18 mars 2025 de 5 sacs de sable (produit 89588), avec la remise Jour fou de 30 % (référence 275).

On suit successivement la clé client, la ligne de vente, la référence produit et la référence remise. La valeur 275 n’est pas un taux : elle identifie la ligne dont le taux est 30. La quantité 5 n’est pas non plus cinq lignes de vente distinctes.

INSERT INTO client (ref_client, nom, prenom, email, telephone)
VALUES (25345, 'Bertaut', 'Gilles', 'gbertaut@fmail.fr', '0641424344');

L’ordre des valeurs correspond à celui des colonnes explicitement nommées. Le téléphone est une chaîne : ses chiffres ne sont pas destinés à un calcul et son zéro initial doit être conservé. Inverser le nom et le prénom donnerait une ligne valide en apparence, mais fausse.

UPDATE client
SET email = 'shars@fmail.fr'
WHERE ref_client = 25322;

La référence 25322 identifie précisément la cliente visible dans l’extrait. Seul l’e-mail est modifié. La clause WHERE évite de modifier l’ensemble des clients ; utiliser la clé est aussi plus robuste qu’un filtre sur un nom susceptible d’avoir des homonymes.

SELECT DISTINCT ref_client
FROM vente
WHERE date >= '2025/01/01';

La date appartient à la vente. Il n’est pas nécessaire de joindre la table client puisque la référence recherchée est déjà présente dans vente. DISTINCT retire les répétitions dues à plusieurs achats d’un même client.

« À partir du » inclut le 1er janvier : on utilise >=, pas >. Les chaînes se comparent correctement dans le format fixe année/mois/jour annoncé, car les composantes sont ordonnées de la plus importante à la moins importante et complétées sur la même largeur.

SELECT DISTINCT c.nom, c.telephone
FROM client AS c
JOIN vente AS v ON v.ref_client = c.ref_client
WHERE v.ref_produit = 90222
  AND v.date >= '2024/09/15';

La table vente permet de sélectionner le produit et la date ; la table client fournit les coordonnées à rappeler. La jointure suit les références clients, et les deux conditions sont réunies avec AND.

La table produit n’est pas indispensable ici : la référence à filtrer est connue. Avec OR, on rappellerait notamment des clients ayant acheté n’importe quel article après la date, ce qui ne correspond pas à la campagne demandée.

def select_tel(client, ref_client):
    return client[ref_client][3]

Le premier accès utilise la clé du dictionnaire, ref_client. Le second sélectionne l’élément d’indice 3 de sa liste : nom en 0, prénom en 1, e-mail en 2, téléphone en 3. Ainsi, pour 25137, le résultat est '0604030201'.

Ce second accès suppose que la liste contient bien quatre éléments. Le dictionnaire illustré dans le PDF omet le téléphone de Franck Eiffel ; cette ligne incomplète provoquerait une autre erreur, étudiée dans l’atelier. Le contrat de la question et l’exemple d’appel concernent une ligne complète.

La clé 1234 n’existe pas dans le dictionnaire client. L’accès client[1234] échoue avant même qu’on essaie de lire le téléphone. Cela correspond à une référence client absente des données utilisées, par exemple une référence saisie incorrectement ou un client qui n’a pas été enregistré.

Il ne s’agit pas d’un mauvais indice dans une liste : cette autre situation déclencherait IndexError. Le nom de l’exception indique donc quelle étape de l’accès a échoué.

def select_tel(client, ref_client):
    if ref_client in client:
        return client[ref_client][3]
    return None

Le test d’appartenance intervient avant l’accès. Si la clé est présente, on utilise la ligne ; sinon on renvoie la valeur spéciale None, sans guillemets. Cette version protège précisément contre une clé absente, comme le demande la question.

Elle ne répare pas une liste d’attributs incomplète pour une clé existante. Ce serait un autre contrôle de données, à ajouter si le contrat de l’application doit couvrir cette situation. Mélanger ces deux erreurs empêcherait de diagnostiquer leur cause.

def nb_produits(vente, ref_produit):
    total = 0
    for ligne in vente.values():
        if ligne[1] == ref_produit:
            total += ligne[3]
    return total

Les valeurs du dictionnaire sont les lignes de vente. L’indice 1 contient la référence produit et l’indice 3 la quantité. À chaque ligne correspondant au produit demandé, on ajoute cette quantité au total.

Ajouter 1 compterait des lignes de vente, pas des unités. Dans l’extrait, le sac de sable apparaît dans une seule vente mais la quantité vendue est 5. Si aucune vente ne correspond, le total reste naturellement à 0.

assert nb_produits(vente, 85235) == 1
assert nb_produits(vente, 89588) == 5
assert nb_produits(vente, 99999) == 0

La vente 25632 référence encore le produit 89363, le niveau à bulle. Supprimer ce produit laisserait une vente pointant vers une référence qui n’existe plus. La clé étrangère de vente interdit cette incohérence et le SGBD refuse donc la suppression.

Ce n’est pas une erreur de syntaxe SQL : le sens de l’opération viole une contrainte du modèle. Le sujet demande de conserver ce refus ; il ne demande pas de supprimer les ventes pour forcer l’opération.

def delete_prod(produit, vente, ref_produit):
    for ligne in vente.values():
        if ligne[1] == ref_produit:
            return False
    if ref_produit not in produit:
        return False
    del produit[ref_produit]
    return True

Avant toute suppression, on parcourt les ventes. Dès qu’une ligne utilise la référence, on quitte la fonction sans modifier produit. C’est seulement après avoir vérifié toutes les lignes que l’on peut supprimer la clé.

La convention choisie ici est de renvoyer False en cas de refus ou de référence absente, et True si la suppression a été effectuée. Le refus serait aussi possible avec un message ou une exception adaptée, mais il doit laisser les dictionnaires inchangés. Ne supprimez pas d’abord le produit en espérant vérifier ensuite les références.

2, 4 et 5. Une balle est disponible en position 0. Les positions positives libres sont 2, 4 et 5 ; 1 et 3 sont déjà réservées à une arrivée. Le lancer 0 est interdit puisque la main contient une balle.

Seulement 0. La main est vide : on attend le temps suivant. La position 3 est libre, mais cela ne suffit pas à autoriser un lancer positif, puisqu’il n’y a pas de balle à envoyer.

def lancer_possible(etat, lancer):
    if lancer >= len(etat) or lancer < 0:
        return False
    if lancer == 0 and etat[0] == 1:
        return False
    if lancer > 0:
        if etat[0] == 0 or etat[lancer] == 1:
            return False
    return True

Le premier test élimine les indices hors du tableau. Pour le lancer 0, la présence d’une balle dans la main suffit à refuser. Pour un lancer positif, deux causes indépendantes imposent un refus : aucune balle disponible, ou un emplacement d’arrivée déjà occupé. On les réunit avec or.

Le retour True n’intervient qu’après avoir éliminé tous ces cas. Cette façon d’écrire est plus facile à contrôler qu’une grande condition unique mêlant bornes, main et destination.

[1, 0, 1, 0, 1, 0]

Avant la gravité, on retire la balle de la main et on l’inscrit en position 5 : [0, 1, 0, 1, 0, 1]. Puis chaque arrivée se rapproche d’un temps : on décale les cases vers les petits indices et on ajoute 0 à la fin. Le nombre de balles reste égal à trois.

def lancer_balle(etat, lancer):
    nouvel_etat = [balle for balle in etat]
    nouvel_etat[0] = 0
    if lancer > 0:
        nouvel_etat[lancer] = 1
    nouvel_etat.pop(0)
    nouvel_etat.append(0)
    return nouvel_etat

La copie protège l’entrée. On libère la main, puis on réserve l’arrivée si le lancer est positif. Le pop(0) effectue le décalage temporel et append(0) conserve la longueur. Pour un lancer 0 valide, aucune balle n’est ajoutée : seules les arrivées existantes se rapprochent.

Écrire nouvel_etat = etat au lieu de la copie créerait un alias, et la suite modifierait l’état fourni. Deux tests utiles sont donc la conservation du nombre de balles et l’égalité de l’entrée avec sa valeur avant l’appel.

def liste_lancers_possibles(etat):
    lancers = []
    for lancer in range(len(etat)):
        if lancer_possible(etat, lancer):
            lancers.append(lancer)
    return lancers

La fonction examine tous les indices autorisés par la taille du tableau, y compris 0. Elle laisse lancer_possible décider lesquels sont valides. On conserve ainsi une seule définition des règles de lancer, au lieu de la recopier avec le risque d’une divergence.

L’ordre croissant produit les listes des exemples. Une fonction qui testerait seulement les positions libres oublierait la condition sur la présence d’une balle dans la main.

Elle s’appelle elle-même dans calcule_sequences(etat2, n - 1). Un premier lancer transforme l’état, puis le même problème est résolu pour une séquence plus courte. La présence de boucles n’empêche pas une fonction d’être récursive.

À chaque appel récursif, le paramètre n diminue de 1. C’est un entier qui atteint donc 0 après un nombre fini d’appels le long de chaque branche. À 0, la fonction renvoie immédiatement [[]], sans nouvel appel. Chaque nœud n’a qu’un nombre fini de branches puisque les boucles sont bornées.

Le nombre de possibilités peut augmenter fortement, mais une exécution longue n’est pas une absence de terminaison. Le raisonnement utilise la précondition n entier non négatif ; il ne justifierait pas un appel avec n négatif.

def calcule_sequences(etat, n):
    if n == 0:
        return [[]]
    else:
        s_possibles = []
        l_lancers = liste_lancers_possibles(etat)
        for lancer in l_lancers:
            etat2 = lancer_balle(etat, lancer)
            s_etat2 = calcule_sequences(etat2, n - 1)
            for sequence in s_etat2:
                s_possibles.append([lancer] + sequence)
        return s_possibles

La liste des premiers lancers provient de liste_lancers_possibles. Pour chacun, lancer_balle construit l’état à partir duquel il reste n - 1 choix à effectuer. Enfin, on préfixe chaque suffixe renvoyé avec [lancer].

Le cas de base [[]] représente une collection contenant une séquence vide. S’il était remplacé par [], la dernière boucle n’aurait aucun suffixe auquel ajouter le premier lancer et toutes les solutions disparaîtraient. La concaténation crée une nouvelle liste et évite de modifier les suffixes réutilisés.

Avec n = 2 et le premier lancer 1, les suffixes sont [1], [4] et [5] ; on construit donc [1, 1], [1, 4] et [1, 5]. Les branches commençant par 2 et 5 ajoutent chacune leur suite terminée par 0.

automate = {
    '11000': [(3, '10100'), (2, '11000'), (4, '10010')],
    '01010': [(0, '10100')],
    '10100': [(1, '11000'), (3, '01100'), (4, '01010')],
    '01100': [(0, '11000')],
    '10010': [(1, '10100'), (2, '01100'), (4, '00110')],
    '00110': [(0, '01100')]
}

Chaque clé représente un état de départ et chaque tuple un arc sortant. Par exemple, le tuple (2, '01100') sous '10010' signifie qu’un lancer 2, gravité incluse, fait passer de cet état à 01100. La boucle (2, '11000') doit être conservée : un lancer peut ramener au même état.

Les six états du graphe possèdent deux balles et une dernière case nulle. Cette dernière case correspond à l’emplacement le plus haut, remis à zéro après le décalage temporel. Il faut recopier les arcs orientés, pas ajouter automatiquement leurs inverses.

def lancer_balle_automate(automate, etat, lancer):
    if etat not in automate:
        return ''
    for etiquette, suivant in automate[etat]:
        if etiquette == lancer:
            return suivant
    return ''

On parcourt seulement les arcs sortants de l’état demandé. Le tuple est décomposé en son étiquette et son arrivée ; la première étiquette égale au lancer fournit la réponse. Si aucun arc ne convient, on renvoie la valeur d’échec imposée, la chaîne vide.

Le contrôle initial de présence de l’état rend aussi la fonction utilisable en cas d’état inconnu. Ne renvoyez pas la chaîne vide dès le premier arc dont l’étiquette ne convient pas : un arc ultérieur peut correspondre.

def parcours_sequence_depart(automate, depart, sequence):
    courant = depart
    for lancer in sequence:
        courant = lancer_balle_automate(automate, courant, lancer)
        if courant == '':
            return None
    return courant

La variable courant représente l’état atteint après les lancers déjà traités. Chaque transition dépend donc de cet état actualisé, et non de l’état initial. Si la fonction précédente renvoie la chaîne vide, on convertit ce signal en None, comme l’exige ce nouveau contrat.

Une suite vide renvoie l’état de départ. Une suite non vide peut être entièrement réalisable sans ramener au départ : cette fonction vérifie le parcours, pas encore la possibilité de répéter la figure en boucle.

def departs_siteswap(automate, sequence):
    departs = []
    for depart in automate:
        if parcours_sequence_depart(automate, depart, sequence) == depart:
            departs.append(depart)
    return departs

On essaie chaque état du dictionnaire comme point de départ. Une séquence est une figure répétable depuis cet état seulement si son parcours est possible et se termine sur le même état. Comparer le résultat au départ vérifie directement ces deux conditions : None ne peut pas être égal à une chaîne d’état.

Tester uniquement resultat is not None accepterait des trajets ouverts qu’on ne pourrait pas nécessairement répéter. Il faut aussi conserver tous les départs valides, pas renvoyer dès le premier succès.